Some trackers don't send information about fuel, or a unit is not equipped with fuel sensors, but users still want to see fuel consumption data in the report.

As an alternative to fuel sensors, you can use Consumption by rates, which is configured on the Advanced tab. Its calculation algorithm is simple: the mileage per interval is multiplied by the specified consumption rate (l/100 km), which may vary depending on the season. But in this article, we will cover another option for calculating fuel consumption without a sensor, which requires more explanation — Fuel consumption by math, aka Math consumption. Moreover, its field of application is not limited to one use case.

Where can you use math consumption?

First of all, math consumption is used in reports to compensate for the absence of fuel sensors or verify their readings. To display the results of a mathematical calculation, add the Consumed by math, Avg consumption by math columns, or other columns that have "by math" in their title to the table.

Math consumption is also used in fuel algorithms. Firstly, to detect fuel drains if the Calculate drains by time option is enabled. Secondly, to calculate the consumption on intervals with invalid values, if the Replace invalid values with math consumption option is enabled. Both mentioned options are in the additional settings of FLS.

How does math consumption work?

The system determines the expected consumption for an interval using a mathematical model. It is built on the basis of:

• engine operation sensors (ignition or absolute/relative engine hours) that indicate the fuel consumption rate at idle;
• engine efficiency sensors (EES), each of which indicates the influence of some factor on fuel consumption (engine rotation speed, temperature, axle load, air conditioning, attached equipment, and so on).

Math consumption per interval is the sum of consumptions between all messages on the interval. The following formula is used to calculate math consumption between the current message and the previous message:

Δt ⋅ ( C_{I 1} + C_{I 2} + ... + C_{I N} ) ⋅ (K_{EES 1} + (K_{EES 2} - 1) + (K_{EES 3} - 1) + ... + (K_{EES M} - 1)),

where Δt — the time between messages; C_{I j} — consumption rate at idle from the j-th engine operation sensor, which was enabled in the considered message; N — the number of engine operation sensors created in the unit; K_{EES i} — the value of the i-th engine efficiency sensor in the considered message; M — the number of engine efficiency sensors created in the unit.

Why bind engine operation sensors, engine efficiency sensors, and FLS?

Some units have several engines. In most cases, this is special-purpose machinery, and a concrete mixer truck is a good example: its main engine makes the vehicle move, and an additional autonomous engine rotates the mixing drum. Accelerating the vehicle or turning on the air conditioner may affect the fuel consumption of the main engine but will not affect the consumption of the additional one. Consequently, some factors affecting consumption (we take them into account using engine efficiency sensors) affect only one of the engines (we take them into account using engine operation sensors). At the same time, the unit may have several fuel tanks (we take them into account using FLS), which also need to be bound with a specific engine.

To bind mentioned sensors, you should enter the properties of the ignition sensor or absolute/relative engine hours sensors and select the appropriate engine efficiency sensors. Similarly, in the FLS properties, you can configure its binding with engine operation sensors.

How to quickly create a mathematical model?

To create a basic mathematical model, use Math Consumption Wizard located on the Sensors tab in the unit properties. In the Math Consumption Wizard window, you need to enter information about fuel consumption in different operating modes, as well as the seasonal coefficient and the season's start and end dates. Let's take a closer look at these fields:

• Fuel consumption (l/h) refers to consumption at idle, i.e., with the engine running and the vehicle not moving. The Min. moving speed is taken from the Trip Detector.
• Urban cycle and Suburban cycle (l/100 km) are standard vehicle characteristics you can find in documents, on the internet, or calculate in practice. At the same time, different countries use different approaches to defining these cycles. In Wialon, the urban cycle rate corresponds to a speed of 36 km/h, and the suburban one — 80 km/h.
• Seasonal coefficient (%) refers to the percentage increase in fuel consumption during the specified season compared to the rest of the year. You can disable the seasonal factor if there are no significant temperature changes throughout the year in the area where the vehicle is used.

By filling in Math Consumption Wizard, you will create a basic mathematical model that considers only the unit speed and seasonal influence. Such a model is approximate because, in practice, speed doesn't affect consumption — the engine rotation speed does, as well as the season doesn't affect consumption — the temperature does. However, by default, most trackers don't send information about engine rotation speed and temperature. That's why we've chosen a model that is suitable for all trackers.

It's impossible to automatically create a more accurate model, but you can do it manually by adding engine efficiency sensors.

How do engine efficiency sensors work?

The value of an engine efficiency sensor in each message should show how many times an influencing factor increases the consumption at idle compared to the consumption without the influence of this factor. For a better understanding, let's look at an example.

Let’s assume that the consumption at idle is 2 l/h, and when the heating system is turned on, the consumption increases to 2.2 l/h. Therefore, the ratio of these values is: 2.2/2 = 1.1
Let's also assume that the in4 parameter indicates the state of the heating system: if this parameter is equal to 0, the heating is off, and if it’s equal to 1, the heating is on.
In this case, to take into account the heating system influence on the consumption, you need to create a sensor with the Engine efficiency sensor type, specify in4 in the Parameter line, and add the following lines to the Calculation Table:

x = 0; a = 0; b = 1
x = 1; a = 0; b = 1.1

So, when the heating system is off, the engine efficiency sensor increases the consumption by 1 time (i.e., it doesn’t change it), and when the system is on, the consumption is increased by 1.1 times. Note that a zero value of the engine efficiency sensor would also not affect fuel consumption.

Using the method described above, you can take into account the influence of one factor on the expected consumption. If there are several engine efficiency sensors, all their values are taken into account simultaneously, forming the expected consumption rate on the interval between two messages (see the formula above).

How to make math consumption more accurate?

We should note that if you activate the Calculate drains by time option in the fuel level sensor properties, the system will compare math consumption with the FLS consumption. Unfortunately, the readings of the latter are not very accurate. Hence, there is no need to try to make an ideal mathematical model since this may not affect the result of comparison with FLS in the end.

However, you can try to increase the model accuracy in the following ways.

Consider more factors

You can create more engine efficiency sensors based on parameters from the tracker that describe factors affecting consumption.

Note that numerous factors influence consumption, but the degree of their influence may vary. For example, there’s probably no need to install an air humidity sensor, although humidity can also affect consumption. It makes more sense to measure tire pressure, but on the other hand, it’s better to avoid using under-inflated tires. But don't expect the high accuracy of the mathematical model if you ignore the cargo weight, which can be measured using an axle load sensor. In other words, you should choose the factors to consider according to the degree of their influence on the result.

Increase the accuracy of parameter measurement

This recommendation follows from the previous one. To improve the result, you can not only increase the number of sensors but also use higher accuracy sensors.

Increase the frequency of messages

If the factors influencing consumption change frequently, the tracker must also generate messages frequently; otherwise, you won’t be able to take all factors into account. For example, this applies to trips around the city, when a car can stand at several traffic lights within 10 minutes. But if only one message is recorded in the tracker's memory during this time, the mathematical model simply cannot take into account each speed change.

Why does math consumption show incorrect values?

There may be several reasons for such behavior.

1. The rates used in Math Consumption Wizard may differ from the actual ones (for example, due to the wear and tear of a vehicle). In this case, you can check their compliance with reality in practice.
2. This may be due to the incorrect setting of math consumption. Check that a non-zero value is specified in the Consumption, l/h line in the engine operation sensor properties. Also, make sure that the engine operation sensor and the engine efficiency sensor are bound.
3. The frequency of messages generated by the tracker may be too low.
4. This may be due to a breakdown of the sensor, which readings are used in the mathematical model.
5. In some cases, the system may think that the ignition was on all the time when the tracker didn’t send messages. In this case, the mathematical model will show that the engine should have been wasting fuel during all this time. To fix the situation, try to set the correct value of the Maximum interval between messages option on the Advanced tab in unit properties. You can achieve the same result using the Timeout option in the ignition sensor properties.

Oleg Zharkovsky,Customer Service Engineer 2022-02-04

This page only highlights the key differences between fuel algorithms. I don’t intend to list all possible combinations of settings from the fuel level sensor properties, although they all affect data processing to a certain extent. To study each option, I recommend watching a webinar or testing it in practice. Notice that you can change settings without worrying about the initial data because changing the fuel options doesn’t change messages but only affects the displayed result.

Which algorithm to choose

Below is a list of algorithm features that should help you make a choice.

Mileage-based algorithm

1. Suitable for most moving units.
2. Relatively easy to set up.
3. Used by default.

Time-based algorithm

1. Suitable
   
   • for stationary units,
   • for units with long idling intervals,
   • for units with vehicle attachments, which increases fuel consumption,
   • if you suspect fuel drains while driving,
   • if the mileage-based algorithm doesn’t produce expected results.
2. More difficult to set up.
3. For activation, it’s recommended to simultaneously enable the following options in the fuel level sensor properties:
   • Calculate fuel consumption by time
   • Calculate fillings by time
   • Calculate drains by time – to process drains, you also need a consumption mathematical model, which you can create, for example, using the Math Consumption Wizard.

What is the difference between algorithms?

First, we should note that, to some extent, a more correct name for the mileage-based algorithm would be a speed-based algorithm because it ignores messages in which speed is less than the Min moving speed set in the Trip detector. But since the mileage increases when moving, the current name is also appropriate.

It follows from the above that the key difference between algorithms is that the time-based algorithm analyzes all messages, while the mileage-based algorithm excludes some of the messages from the analysis, using simplification. It is based on the fact that you can assess the fuel level change during stops or parkings (i.e., on the low-speed interval) by two messages before and after a given stop or parking. For example, if a vehicle was in the parking lot from 14:00 to 16:00, and the fuel drain happened between 15:00-15:10, you can learn about the fact of drain simply by comparing fuel levels at 14:00 and 16:00.

Consumption

Both algorithms calculate consumption for an interval similarly: the fuel level value at the end of the interval is subtracted from the fuel level value at the beginning of the interval, and then the volume of fuel filling for this interval is added to them. However, the key difference between algorithms still implies that they take into account different intervals.

In addition, I’d like to note that the drain volume is included in the consumption by default until the Exclude drains from fuel consumption option is activated in the report template settings.

Fuel fillings

Detecting fillings is also the same for both algorithms: the system searches for messages with a sequential increase in the fuel level sensor readings. However, the mileage-based algorithm calculates fuel fillings during stops by only two points (fuel level at the end of the previous movement interval and at the beginning of the next one), without analyzing all messages for the given interval.

Fuel drains

Drain are detected using different methods:

• The mileage-based algorithm detects the drain during parking by two points (fuel level at the end of the previous movement interval and at the beginning of the next one), without analyzing all messages for the given interval.
• The time-based algorithm compares the actual consumption according to the fuel level sensor with the expected consumption determined by the mathematical model.

Oleg Zharkovsky,Customer Service Engineer 2021-12-08

Fuel fillings are displayed in reports when the data received from the tracker meets all the criteria for detecting fillings. However, in some cases, the Fuel fillings and battery charges table doesn’t display the results, although you know for sure that the fuel filling was performed, and the chart in the report shows a sharp increase in the Fuel level line. By following simple recommendations from this article, you can fix the situation and understand the logic of some fuel settings.

Possible causes and their elimination

Sometimes, it will be enough to follow only one recommendation from the list below to solve a problem. More often, you will have to follow several tips at once. But in some cases, you won’t be able to avoid detailed analysis of all fuel level sensor settings, as well as of the features of incoming messages and parameters.

At the same time, fixing the situation with the displaying of one filling often results in the emergence of other inconsistencies in fuel reports. That’s why there should be a comprehensive approach to the fuel data analysis, considering not one filling but several at a time.

1. Filling is ignored due to smoothing

Try to reduce the filtration level in the fuel level sensor settings.

You can also try enabling adaptive median filtration.

2. Filling is filtered by volume

Try to reduce the value of the Minimum fuel filling volume option in the fuel level sensor settings.

3. Filling takes place in motion

Adjust the Trip Detector settings by increasing the Min moving speed ​​if the speed is not related to the actual trip of the unit but is related to the error in the initial data. However, if the speed in such messages is comparable to the speed of actual trips (for example, more than 10 km/h), you can probably delete such messages, and to avoid similar situations in the future, you can try to filter them out. Please keep in mind that you will not be able to recover messages deleted manually or as a result of message validity filtration, so pay special attention to these steps.

Another method for solving a problem is to enable the Detect fuel filling only while stopped option and increase Timeout to detect final filling volume in the fuel level sensor settings.

4. Filling is marked as false and then hidden

Try to enable the Show false events option in the report template settings. Then execute the report again and unmark the filling so that it isn't regarded as a false one.

Oleg Zharkovsky,Customer Service Engineer 2022-01-13

Fuel drains are displayed in reports when the data received from the tracker meets all the drain detecting criteria. However, in some cases, the Fuel Drains table doesn’t show the results, although you know for sure that fuel was drained and can see a sharp drop in the Fuel level chart in the report. By following simple recommendations from this article, you can fix the situation and understand the logic of some fuel settings.

Possible causes and their elimination

Sometimes it will be enough to follow only one tip from the list below. More often, you will have to follow several recommendations at once. But in some cases, you won’t be able to avoid detailed analysis of all fuel level sensor settings, as well as of the features of incoming messages and parameters.

At the same time, fixing the situation with the displaying of one drain often results in the emergence of other inconsistencies in fuel reports. Thus, there should be a comprehensive approach to the fuel data analysis, considering not one drain but several at a time.

1. Drain is ignored due to smoothing

Try to reduce the filtration level in the fuel level sensor settings.

You can also try enabling adaptive median filtration.

2. Drain is filtered by volume

Try to reduce the value of the Minimum fuel drain volume option in the fuel level sensor settings.

3. Drain takes place during short stops

Try to reduce the Minimum stop duration to detect a fuel drain in the fuel level sensor settings.

4. Drain takes place in motion

Activate the Detect fuel drain in motion option in the fuel level sensor settings if the unit was actually moving at the moment of drain. Please note that in this case, in order to display the correct result, it’s recommended to enable the Calculate drains by time.

Another method is to increase the minimum moving speed on the Trip Detector tab if the speed is not related to the actual trip of the unit but is related to the error in the initial data. However, if the speed in such messages is comparable to the speed of actual trips (for example, more than 10 km/h), you can probably delete such messages, and to avoid similar situations in the future, you can try to filter them out. Please keep in mind that you will not be able to recover messages deleted manually or as a result of message validity filtration, so pay special attention to these steps.

5. Drain is marked as false and then hidden

Try to enable the Show false events option in the report template settings. Then execute the report again and unmark the drain so that it isn't regarded as a false one.

Oleg Zharkovsky,Customer Service Engineer 2024-02-12

If data received from the tracker meets all the drain detecting criteria, the Fuel Drains table will contain records about it, even if there was no actual drain. Such fuel drains are called false.

To correctly configure fuel drain detection, you need to know not only the technical features of Wialon algorithms but also the operating principles of hardware (trackers, sensors, and the unit's fuel system). This article provides simple instructions, following which you can eliminate false fuel drains by focusing on the fuel level chart only.

Required steps before applying instructions

• A unit is created in Wialon, data messages from the tracker are displayed in the system.
• The fuel level sensor is connected to the tracker, the fuel tank is calibrated.
• A sensor with the Fuel level sensor (FLS) type is created in the unit.
• The Calculate data by the sensor option is activated in the FLS settings.
• The calibration table (XY pairs) is added to the fuel level sensor Calculation table, whereafter the Generate button is clicked.
• A report template with a Regular type chart is created, which displays the Processed fuel level.
• The chart also displays fuel drain markers and the background of trips (it's pink by default), stops (blue), and engine hours (yellow).

Chart behavior in the location of false fuel drain

Choose one of the options below according to what you see on the chart where the fuel drain marker is located.

1. Jumps during motion or engine operation

During engine operation, driving on uneven surfaces or basically any movement, fuel fluctuations occur, and the FLS reads them. Depending on the tank volume and shape, as well as the FLS location, these fluctuations can reach dozens of liters, which can result in detected fuel drains. In general, you can compensate them with the help of a smoothing algorithm.

To do this, set filtration type to Adaptive median filtration in the fuel level sensor settings. In this case, the algorithm automatically calculates the appropriate value of filtration level.

As an alternative you can set filtration type to Median filtration to manually tune the smoothing algorithm. E.g. set the filtration level to 3. Keep in mind that high filtration levels should be used only with a high frequency of message sending (1-5 seconds between messages). After applying the filtration, fuel algorithms will work not with the raw data but with smoothed data.

To check if smoothing is effective, add the Fuel level line (before smoothing) to the chart and compare it with the Processed fuel level line (after smoothing). If the Processed fuel level line fluctuations still seem significant to you, try to increase the filtration level (an increment of 1 is recommended). But don't forget that smoothing may distort the input data, that's why you have to find the middle ground: Processed fuel level line fluctuations no longer seem significant (or they are eliminated), but at the same time, the lines before and after smoothing are still not much different in distinctive points (for example, during actual fillings/fuel drains).

2. A sharp jump immediately after the start or stop of motion

FLS readings can change abruptly at the moment of motion start/stop, which can result in fuel drain detection. If the chosen filtration level doesn't smooth out these jumps, and you don't want to increase it (for example, in your case, this causes significant distortion of input data at other intervals), then you can use one of the two time filters in the fuel level sensor settings:

• Ignore messages after the start of motion — this option allows you to exclude a specified number of seconds after starting the movement from the fuel drain analysis.
• Minimum stop duration to detect a fuel drain — if the duration of the interval without movement doesn't exceed the specified one, then this interval won't be analyzed for fuel drains (thus, you can cut off fuel level fluctuations, for example, during short stops at traffic lights).

3. Smooth falling with the running engine and no movement

There are two algorithms for fuel analysis in Wialon: the mileage-based algorithm (used by default) and the time-based algorithm. For stationary units and units with long idle intervals, it's recommended to use the time-based algorithm. To do this, activate three options in the fuel level sensor settings: Calculate fillings by time, Calculate drains by time, and Calculate fuel consumption by time. We should clarify that in this very case, it would be possible to do only with the Calculate drains by time option, but the simultaneous activation of all options will allow you to achieve better convergence of all fuel indicators in the reports.

When using the time-based algorithm, the FLS fuel consumption value is compared with the calculated fuel consumption value, i.e., with the value calculated by the mathematical model. At idle intervals, the calculated fuel consumption value is generally determined by the engine ignition sensor or engine hours counters. Therefore, open the ignition or engine hours sensor properties and check if the correct consumption rate per hour is set in the Consumption field.

4. Fuel drain during driving, although the chart looks normal

Most likely, you are using the time-based fuel analysis algorithm, and you've also activated the Detect fuel drain in motion option in the fuel level sensor settings. In this case, the FLS fuel consumption value is compared with the mathematically calculated consumption. If the consumption by calculation is set incorrectly, a false fuel drain can be detected when the unit is just making a trip; therefore, it's recommended to check the mathematical model of the calculated consumption. It's set via:

• engine ignition sensors or engine hours counters — in the properties in the Consumption field specify the consumption rate per hour at idle;
• engine efficiency sensors — this sensor can use any parameter that affects fuel consumption and based on its value, it determines the fuel consumption change coefficient, which is then multiplied with the consumption value from the previous point.

A basic mathematical consumption model can be created using the Math consumption wizard on the Sensors tab in the unit properties. This model includes the affect of speed and season on the consumption with a help of engine efficiency sensors. Further, you can complement this model, adding more engine efficiency sensors that take into account other factors affecting the consumption (cargo weight, temperature, operation of vehicle attachments, and so on).

5. Significant jumps to the minimum/maximum

If the chart shows jumps of the Processed fuel level line to 0 or to the maximum value (often 2¹⁶-1 = 65535) and back to the actual value, then even after applying the smoothing, these jumps can cause the detection of false drains. Such jumps in readings can be connected with the wrong configuration or the connection of the fuel level sensor itself.

It's recommended to fix this problem on the hardware side; however, on the Wialon side, you can try to cut off these readings using the Calculation table. To do this, go to the FLS settings, go to the Calculation table tab, and set the values of the Lower bound and/or the Upper bound corresponding to an empty and full tank. In the lower bound, however, it's better to set not 0 but a value close to zero (for example, 0.1) to cut off false jumps in readings to 0.

6. Significant jumps not to the minimum/maximum

If the FLS readings change by significant values (but not to 0 or the maximum value) and then return to the actual value, even after applying the smoothing, these jumps can cause the detection of false drains. Such behavior can be connected with voltage surges, which can be seen on the chart using the Voltage line if you have a Voltage sensor.

It's recommended to fix such situations on the hardware side; however, on the Wialon side, you can try to neutralize the impact via Validation. To do this, follow the instructions:

1. Open the Messages tab and request raw data messages for the interval that includes the considered fuel level jump.
2. Manually or using a filter, find another parameter that changes simultaneously with the FLS readings.
   Suppose this is the pwr_ext parameter, which for most trackers corresponds to the external voltage.
3. Determine, upon passing which value of the found parameter, the FLS readings change.
   Suppose that if pwr_ext is less than 12, then the FLS starts sending incorrect readings.
4. Enter the unit properties and create a sensor with the Custom digital sensor type using the parameter from point 3, and then define a Calculation table for it with the following lines:
   X = 0; a = 0; b = 0
   X = 12; a = 0; b = 1
5. Save the created sensor and the changes of unit properties by clicking OK twice.
6. Enter the unit properties again, and then the FLS properties. Specify the sensor from point 4 as a validator with the Not-null check type.

In the example above, a real case is considered since low voltage actually often leads to the distortion of readings of different sensors. This means there is a direct connection between the transmitted parameters of voltage and fuel level. However, you can also use a correlation if you notice a simultaneous change in the FLS readings and any other parameter. Perhaps the tracker doesn't send a voltage value, but it does send a temperature value, and the temperature sensor also fails and sends, for example, 451 °F at the moment of a power surge. In this case, using validation, try to connect the FLS and the temperature value, which should also correct the situation.

7. Smooth falling after filling when there are several interconnected tanks with an FLS in each

Such a change in the FLS readings may be because the unit has several interconnected tanks and fuel flows between them. After filling one of the tanks, the equalization of levels between several tanks may take some time. If you created fuel level sensors in Wialon separately, the system can detect false drain in one of the tanks immediately after filling.

When working with several interconnected tanks, we recommend you to create a Custom sensor for each FLS (for example, named “FLS 1” and “FLS 2”) and add your calibration table into them. After that, create a separate sensor with the Fuel level sensor type, don't add the calibration table into it, but instead just use the following formula: [FLS 1]+[FLS 2]

8. Sharp falling when reaching a certain level

This situation can be observed for tanks of a specific shape at the moment of transition from a wide part to a narrow one (for example, L-shaped tanks). This is particularly likely if the calibration was performed using too few points, and often it's done using only two points (for an empty and full tank). Therefore, it makes sense to re-calibrate the tank using small portions.

9. Smooth change at the same time

Sometimes the fuel level drops/rises at specific points in time, and in some cases, later even returns to the actual value. This can happen at night, or during a trip (especially when loaded), or after approximately equal time after the end of the trip — it's difficult to identify a common rule.

Possible reasons:

• temperature change, affecting the fuel volume and the tank deformation (this is especially true for flexible plastic tanks);
• a "vacuum" created due to the pressure difference (active intake of fuel into the engine);
• sedimentation of impurities in the fuel or dirt in the tank, happening after the end of the trip (shaking).

The solution in most cases is related to the hardware: using a fuel tank cap with a valve to equalize pressure, dirt/sediment removal in the tank or on the FLS. However, if the situation is related only to temperature changes, then using a sensor with the Temperature coefficient type can help you (you can find an example of its setting in the documentation).

Oleg Zharkovsky,Customer Service Engineer 2024-02-12

Fuel control is one of the strengths of Wialon. The system has long been able to calculate the actual and expected fuel consumption for groups and individual units, as well as track fuel fillings and drains in real time or for the past period. But Wialon has another important tool for fuel control, which may not be known to everyone, although it opens up a unique opportunity for accounting dispenses by refuelling trucks. We are talking about the Fuel Traffic table, and this is what is considered in this article.

Table features

The Fuel Traffic table is unusual for several reasons. In fact, it combines three tables: Fuel Fillings and Battery Charges, Fuel Drains, and Counter Sensors. Despite the fact that it is not available for unit groups, when you run a report on a refuelling truck it can display data for other units that receive fuel (namely, customer units).

This table can be used in different ways:

1. For a refuelling truck to display fuel dispensing to customer units.

2. For any unit to display all its fuel fillings and drains in one list.

3. Combining the first and second methods to see both fuel fillings and dispensing of a refuelling truck.

Only the first method is considered further in the article since it requires more non-standard settings comparing with the second one.

Necessary sensors

The logic of the table

Let's take a step-by-step look at the operation logic of the Fuel Traffic table for the case when it is executed for a refuelling truck.

When running a report for the selected interval, the table searches the refuelling truck for Fillingies of various types: fuel fillings, drains, or counter performance. The search is carried out in the same way as in the tables of the same name — Fuel Fillings and Battery Charges, Fuel Drains, and Counter Sensors. It is possible to filter the types of fuel actives to be displayed in the table settings. The logic of working with all three types of activities is the same. For simplicity, let's assume that only fuel dispensing is considered in the example.

Next, the system looks for potential customers, that is, other units that were close to the refuelling truck during its fuel activities. The distance to these units is compared with the radius of approximation, which is specified in the settings of the Fuel Traffic table. Let's assume that several such units are found.

The next step, the system starts searching for fuel fillings for the units found nearby. The search is carried out in the same way as in the Fuel Fillings and Battery Charges table.

If the Include only units with tank fuelling option is enabled in the table settings, then units without fillings will be excluded from further analysis and display. And if this option is disabled, then the report will include even those units that were simply near the refuelling truck at the time of fuel activities, but did not have fillings. Let’s suppose that the option Include only units with tank fuelling is enabled in our example.

At the moment, the system has already calculated the refuelling truck activity intervals and the filling intervals of customer units. Now we need to adjoin them.

If the filling time of a potential customer falls within the fuel activity, then the filling and fuel activity are considered to be adjacent. If such a hit did not happen, then the algorithm looks for intersections of the filling interval with the interval of fuel activity. If there are several such intersections, then the filling will be adjacent to the first fuel activity in terms of time. If the filling interval does not intersects with any fuel activity, then the customer unit and its filling will not be displayed in the report.

In the example shown in the pictures, we get:

• The fuel activity 1 row will display the fuel filling of the potential customer 1.
  In this case, the filling time (maximum fuel level difference) of the customer unit falls within the dispensing interval.
• The fuel activity 2 row will display the fuel filling of the potential customer 2.
  The time of this filling does not fall within the dispensing intervals, however, the fuel filling has intersections with several dispensing activities and will be related to the very first one.
• No fuel fillings will be displayed in the fuel activity 3 row.
  The filling interval of the potential customer 3 does not overlap with any fuel dispensing.
• The potential customer 4 will not be displayed in the report.
  No fuel fillings were detected for it, and according to the condition of the example, the option Include only units with tank fuelling is enabled in the table settings.

The names of the customer units will be displayed in the Geofences/Units column, the Filled column will contain the volume of the customer unit fuel fillings, and the Deviation column will contain the difference between fuel filling and dispensing.

Example of settings for fuel dispensing control

Let's consider an example of setting up the Fuel Traffic table to control dispensing by a refuelling truck. By default, this table displays all types of fuel activities, so you must first hide the unnecessary ones, and then configure the remaining ones.

Please remember that the settings may vary depending on the equipment used and its accuracy, as well as the needs of the client. However, most of the steps in the instructions below are still the same for all users.

• To hide refuelling truck fillings, open the Fillings block in the interval filtration, enable the Fuel fillings filter in it, and select the option Without fillings in the drop-down menu.
  
  
  
• If the fuel dispenser does not have a fuel filling gun with flow meter installed, while other counter sensors are created for the unit, they may affect the displayed result.
  To hide the readings of these counters, open the Sensors block in the interval filtration, enable the Sensor masks filter in it, and specify a name that does not match the names of the counters.
  
  
  
• If a refuelling truck is equipped with a fuel filling gun with flow meter, it is recommended to work with its data and not with fuel drains detected by the FLS.
  To hide fuel drains from the fuel dispenser, open the Drains block in the interval filtration, enable the Fuel drains filter in it, and select the Without drains option in the drop-down menu.
  
  
  

• Depending on the previous steps, at this stage the report will only display the acts of fuel dispensing recorded by the FLS or by the counter.
  In both cases, to display customer units and their fillings, it is necessary to mark the necessary units or unit groups in the Geofences/Units filter and specify the radius of approximation. This filter is repeated in each of the blocks (Fillings, Drains, Sensors), so you need to configure it in the block that you plan to use.
  It is also recommended to enable the Include only units with tank fuelling option to hide the units that were just nearby but did not have fillings from the report results.
  
  

  If several units were found nearby, the report displays the name of the unit with the smallest radius of approximation. If the radii match, then all units are displayed in the report.

Solving possible issues

Below we consider common issues that arise when working with the Fuel Traffic table and methods for solving them.

Dispensing or filling volumes do not converge

If the volumes in the Fuel Traffic table do not converge, then you need to perform the same actions as if the incorrect results were in the Fuel Fillings and Battery Charges, Fuel Drains, and Counter Sensors tables. You can verify:

• The availability of sensor parameters in messages from the truck and the customer unit.
  
• Calibration of the refuelling truck and customer unit tanks.
• Refuelling truck counter coefficient (if used).
• Additional settings for the fuel sensors of the refuelling truck and the customer unit.
  

You might find our other fuel-related articles in the Miscellaneous section helpful.

The customer unit is not displayed or is displayed incorrectly

This issue may be related to the inaccuracy in determining the location of the refuelling truck or customer units.

You can check location-related tracker configurations or increase the radius of approximation in the settings of the Fuel Traffic table.

Based on the logic of the table discussed above the issue may be related to how and when a dispensing of a refuelling truck or a filling of a customer unit are detected. Therefore, you can follow the recommendations from the previous paragraph about the inconsistency of the volumes of dispensing or filling.

The dispensing is divided into several parts

If the dispensing is determined by the counter, then you can set the merge intervals condition in the Sensors section in the settings of the Fuel Traffic table. For example, if you set the Timeout less than 30 seconds, then the counter intervals with less than 30 seconds in between will be merged.

If the dispensing is determined by the FLS, then you can increase the Timeout to separate consecutive drains in the FLS properties.

The acts of dispensing are not split

A possible cause of this issue is the low frequency of sending data, due to which it is not possible to receive a sufficient number of messages between the acts of dispensing from the tracker.

You can also apply the recommendations from the previous paragraph, but vice versa: reduce the Timeout less then in the merge intervals condition or reduce the Timeout to separate consecutive drains in the FLS properties.

Lots of little extra acts of dispensing

It is possible that the fuel filling gun through which the fuel is dispensed is leaking, that is, fuel is dripping through it even when closed.

It would be most correct to repair the equipment, however, from the Wialon side, you can set the minimum Counter sensor value range in the Fuel Traffic table settings which will allow you to ignore small dispensing.

Drivers are not displayed correctly

Drivers may not appear in the report, or the same driver may appear in all rows.

There is no single instruction for fixing such a issue, since the process of working with drivers depends on the equipment used.

Try to study the logic of automatic assignment and separation of drivers. You may need to verify:

• Availability of driver assignment sensor parameters in the messages from the refuelling truck.
  
• Driver assignment sensor settings including the separation code.
  
• Properties of drivers, namely, their codes.
  
• Settings of the automatic assignment list.
  

Oleg Zharkovsky,Customer Service Engineer 2023-01-25